1. Field of the Invention
The present invention relates to a method and system for converged IP messaging service, and in particular, to a method and system for managing message threads in converged IP messaging service.
2. Description of the Related Art
Many different messaging services, such as Short Message Service (SMS), Multimedia Messaging Service (MMS), email, Instant Messaging (IM) service, etc., exist today. Although these services rely on different technologies, user experiences the services provide partially overlap with each other. For example, it is possible to send text messages using all the services cited above, and all services above except for SMS can support the transfer of multimedia content.
Recently, there has been an emergence of a new type of converged messaging service in which the above-mentioned messaging services are synthetically converged. As used herein, such a converged messaging service is called a “Converged IP Messaging (CPM) service.” The CPM service is an Session Initiation Protocol (SIP)-based service and is required to be capable of freely performing message communication with users of existing messaging services as well as users of the CPM service. Therefore, the CPM service needs to be capable of inter-working with the existing SMS service, IM service, MMS, Push to talk over Cellular (PoC) service, etc. Further, inter-working between a messaging service through established sessions and a messaging service without establishment of sessions should be possible, and thus standardization of such inter-working is now being in progress.
Usually, message transmission/reception in a CPM system is performed according to a process as shown in FIG. 1, and message transmission/reception in an SMS system is performed according to a process as shown in FIG. 2. In order to help understanding of the message transmission/reception process in each system, FIGS. 1 and 2 are based on an assumption that each system includes two users, although each system allows message transmission/reception between multiple users. It is also assumed here that users do not explicitly establish a session before exchanging the messages, i.e. the user who wants to start a conversation can send a message immediately without first requesting the creation of a session.
The CPM service is based on an SIP that provides a protocol to initiate, modify and terminate a session between users. To send messages without initiating a session first, the CPM relies on the SIP MESSAGE extension. FIG. 1 illustrates a typical flow of a message sent from a first user and a second user, represented by a first CPM client 1 and a second CPM client 3 respectively, via a CPM server 2.
In step 101, the first CPM client 1 sends a typical SIP MESSAGE having a configuration as shown in Table 1 to the CPM Server 2.
TABLE 1MESSAGE sip:user2@domain.com SIP/2.0Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkseMax-Forwards: 70From: sip:user1@domain.com;tag=49583To: sip:user2@domain.comCall-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Type: text/plainContent-Length: 18Hello Mark, are you there?
In step 103, the CPM server 2 receives the SIP MESSAGE, identifies if the second CPM client 3 is registered in the CPM server 2, and forwards the SIP MESSAGE having a configuration as shown in Table 2 to the second client 3.
TABLE 2MESSAGE sip:user2@domain.com SIP/2.0Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghdsVia: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4Max-Forwards: 69From: sip:user1@domain.com;tag=49394To: sip:user2@domain.comCall-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Type: text/plainContent-Length: 18Hello Mark, are you there?
The second CPM client 3 receives the message in step 103, and sends back a “200 OK” message having a configuration as shown in Table 3 to the CPM server 2 in step 105.
TABLE 3SIP/2.0 200 OKVia: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;received=192.0.2.1Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;received=1.2.3.4From: sip:user1@domain.com;tag=49394To: sip:user2@domain.com;tag=ab8asdasd9Call-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Length: 0
Upon receiving the “200 OK” from the second CPM client in step 105, the CPM server 2 forwards a “200 OK” message having a configuration as shown in Table 4 to the CPM client 1 in step 107.
TABLE 4SIP/2.0 200 OKVia: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;received=1.2.3.4From: sip:user1@domain.com;;tag=49394To: sip:user2@domain.com;tag=ab8asdasd9Call-ID: asd88asd77a@1.2.3.4CSeq: 1 MESSAGEContent-Length: 0
The SMS follows the protocol defined in 3GPP [TS 23.040]. FIG. 2 illustrates a typical message processing flow when a first Mobile Station (MS) 4 sends a Short Message (SM) to a second MS 6 via a Short Message Service Center (SMSC) 5.
In step 201, the first MS 4 submits an SM to the SMSC 5 by using an SMS_SUBMIT Protocol Data Unit (PDU). At this time, the first MS 4 can also request an SMS status report (SMS_STATUS_REPORT).
Upon receiving the SMS_SUBMIT PDU, the SMSC 5 confirms the reception of the SMS_SUBMIT PDU by sending an SMS_SUBMIT_REPORT PDU back to the first MS 4 in step 203.
In step 205, the SMSC 5 forwards the SM to the second MS 6 through an SMS_DELIVER PDU. Then, in step 207, the second MS 6 acknowledges the reception of the SM by sending an SMS_DELIVER_REPORT PDU back to the SMSC 5. Upon receiving the SMS_DELIVER_REPORT PDU, the SMSC 5 sends an SMS_STATUS_REPORT PDU to the first MS 4 to report that the SM was successfully delivered to the second MS 6 in step 209.
The SMS_SUBMIT PDU includes information elements (from [TS 23.040]) as shown in Table 5.
TABLE 5Abbr.ReferenceP1)P2)DescriptionTP-MTITP-Message-M2bParameter describing the Type-Indicatormessage type.TP-RDTP-Reject-MbParameter indicating whether or Duplicatesnot the SC shall accept anSMS-SUBMIT for an SM still held in the SC which has the same TP-MR and the same TP-DA as a previously submitted SM from the same OATP-VPFTP-Validity-M2bParameter indicating whether or Period-Formatnot the TP-VP field is present.TP-RPTP-Reply-PathMbParameter indicating the request for Reply Path.TP-UDHITP-User-Data-ObParameter indicating that the Header-IndicatorTP-UD field contains a Header.TP-SRRTP-Status-Report-ObParameter indicating if the MS Requestis requesting a status report.TP-MRTP-Message-MIParameter identifying theReferenceSMS-SUBMIT.TP-DATP-Destination-M2-12oAddress of the destination SME.AddressTP-PIDTP-Protocol-MoParameter identifying the above Identifierlayer protocol, if any.TP-DCSTP-Data-Coding-MoParameter identifying the codingSchemescheme within the TP-User-Data.TP-VPTP-Validity-Oo/7oParameter identifying the time Periodfrom where the message is no longer valid.TP-UDLTP-User-Data-MIParameter indicating the length Lengthof the TP-User-Data field to follow.TP-UDTP-User-DataO3)
The SMS_DELIVER PDU includes information elements (from [TS 23.040]) as shown in Table 6.
TABLE 6Abbr.ReferenceP1)R2)DescriptionTP-MTITP-Message-Type-M2bParameter describing the Indicatormessage type.TP-MMSTP-More-MbParameter indicating whether Messages-to-Sendor not there are more messages to sendTP-RPTP-Reply-PathMbParameter indicating that Reply Path exists.TP-UDHITP-User-Data-ObParameter indicating that the Header-IndicatorTP-UD field contains a HeaderTP-SRITP-Status-Report-ObParameter indicating if the IndicationSME has requested a status report.TP-OATP-Originating-M2-12oAddress of the originating AddressSME.TP-PIDTP-Protocol-MoParameter identifying the Identifierabove layer protocol, if any.TP-DCSTP-Data-MoParameter identifying the Coding-Schemecoding scheme within the TP-User-Data.TP-SCTSTP-Service-Centre-M7oParameter identifying time Time-Stampwhen the SC received the message.TP-UDLTP-User-MIParameter indicating the length Data-Lengthof the TP-User-Data field to follow.TP-UDTP-User-DataO3)
The TP-UD (User Data) contains the message to be sent. The message can be preceded by a header inside the TP-UD. The presence of the header is indicated by the TP-UDHI (User Data Header Indicator) information element, i.e., a TP-UDHI set to “1” indicates that TP-UD is a header.
The header in the TP-UD may be structured as shown in Table 7 (from [TS 23.040]).
TABLE 7FieldLengthLength of User Data Header1 octetInformation-Element-Identifier “A”1 octetLength of Information-Element “A”1 octetInformation-Element “A” Data0 to “n” octetsInformation-Element-Identifier “B”1 octetLength of Information-Element “B”1 octetInformation-Element “B” Data0 to “n” octetsInformation-Element-Identifier “X”1 octetLength of Information-Element “X”1 octetInformation-Element “X” Data0 to “n” octets
The “Information-Element-Identifiers” are predefined values; they all refer to a specific meaning. The list of identifiers and their meaning (for SMS only) are shown in Table 8 (from [TS 23.040]):
TABLE 8VALUEClassifi-Repeat-(hex)MEANINGcationability00Concatenated shortSMSNomessages, 8-bitControlreference number01Special SMS MessageSMSYesIndicationControl02ReservedN/AN/A03Value not used toN/AN/Aavoid misinterpretationas <LF> character04Application portSMSNoaddressing scheme,Control8 bit address05Application portSMSNoaddressing scheme,Control16 bit address06SMSC Control ParametersSMSNoControl07UDH Source IndicatorSMSYesControl08Concatenated shortSMSNomessage, 16-bitControlreference number09Wireless ControlSMSNote 3Message ProtocolControl. . .. . .. . .. . .1B-1FReserved for futureN/AN/AEMS features (seesubclause 3.10)20RFC 822 E-Mail HeaderSMSNoControl21Hyperlink format elementSMSYesControl22Reply Address ElementSMSNoControl23Enhanced Voice MailSMSNoInformationControl24-6FReserved for future useN/AN/A70-7F(U)SIM Toolkit SecuritySMS ControlNote 1Headers80-9FSME to SME specific useSMSNote 2ControlA0-BFReserved for future useN/AN/AC0-DFSC specific useSMSNote 2ControlE0-FFReserved for future useN/AN/ANote 1:The functionality of these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, the repeatability is not within the scope of this document and will not be determined here.Note 2:The functionality of these IEIs is used in a proprietary fashion by different SMSC vendors, and therefore, are not within the scope of this technical specification.Note 3:The functionality of these IEIs is defined by the WAP Forum and therefore the repeatability is not within the scope of this document and will not be determined here.
The message transmission according to the above-mentioned process may be performed either only once between two users or repeatedly multiple times between the same two users. That is, the users may exchange messages like a conversation through the SMS or CPM service. In this process, two users can handle a conversation by just exchanging a series of messages to each other without explicitly establishing a session beforehand. Therefore, messages that are transmitted to or received from the same counterpart are displayed on an individual window of a user. The same concept is also applicable to the CPM service in which messages are transmitted/received after setup of a session. It is impossible to display a set of messages, which a CPM client has transmitted to or received from the same counterpart according to the CPM service, in a single window, for example, a conversational view. Further, it is also impossible to provide a conversational view including previously exchanged messages in the case of restarting the conversation later, because messages are not bound to any particular session, and thus are not linked to each other.